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ABSTRACT 



A method and apparatus for controlling credit card use. As 
described in one aspect of the disclosure, a method is 
disclosed for facilitating communication between a first 
person (e.g., an account holder) and a second person (e.g., a 
user) so that the first person may authorize a transaction 
between the second person and a third party (e.g., a 
merchant). The method comprises the steps of linking the 
first and second persons to a financial account that is used for 
the transaction, receiving data identifying the financial 
account and the third party from the third party, inquiring 
whether the first person desires to communicate with the 
second person based on the data identifying the financial 
account, and enabling communication between the first and 
second persons based on a response to the inquiry from the 
first person and the data identifying the third party. In this 
way, the first person can control the authorization or denial 
of a transaction executed by a user based on circumstances 
surrounding the transaction. 

20 Claims, 8 Drawing Sheets 
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METHOD AND SYSTEM FOR 
CONTROLLING AUTHORIZATION OF 
CREDIT CARD TRANSACTIONS 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application is a continuation of U.S. patent applica- 
tion Ser. No. 09/036,131 entitled "METHOD AND SYS- 
TEM FOR CONTROLLING AUTHORIZATION OF 
CREDIT CARD TRANSACTIONS" filed in the name of 10 
Jay S. Walker, Daniel E. Tedesco, Andrew S. Van Luchene 
and James A. Jorasch filed on Mar. 6, 1998 now U.S. Pat. 
No. 5,999,596. 

FIELD OF THE INVENTION 

15 

The present invention enables a first person who holds a 
credit card account to control a second person's use of a 
credit card that is linked to the account. More specifically, 
this invention relates to a method and system for enabling 
the first person to communicate with the second person who 2 o 
is using the credit card to execute a transaction with a 
merchant and for allowing the first person to authorize or 
decline the transaction based on the communication. 

BACKGROUND OF THE INVENTION 

25 

A bank or other issuer issues credit cards having corre- 
sponding credit card accounts to individuals (hereafter, 
"account holders"). A credit card account typically has a 
credit line associated therewith, which indicates a maximum 
monetary amount that may be charged to the account. An 3Q 
account holder may use his credit card to purchase goods 
and/or services (collectively, "goods") from one or more 
merchants in an aggregate amount that may not exceed the 
credit line for the account. 

It is common for an account holder to permit another 35 
person (hereafter, "user") to purchase goods using a credit 
card that is linked to the account holder's account. When 
doing so, however, it is possible that the user may abuse 
privileges afforded by the credit card and thus may embark 
on a frivolous and costly spending spree for which the 40 
account holder is ultimately responsible. 

The potential for such abuse is readily apparent in the case 
in which a parent permits a child to purchase goods using a 
credit card that is linked to the parent's account. The parent 
may attempt to curtail the potential abuse by providing 45 
guidelines to the child concerning appropriate uses of the 
credit card. Thus, the parent may instruct the child that the 
credit card is to be used only in cases of "emergency." 
However, for any number of reasons, such guidelines and 
instructions may be insufficient to prevent the abuse. For 50 
example, the parent's definition of an "emergency" may 
differ greatly from that of the child's thus resulting in 
charges to the credit card that would be deemed inappro- 
priate by the parent. 

Parents and other account holders are currently limited in 55 
their ability to control and manage charges made by users 
using credit cards that are linked to their accounts. While 
certain known techniques endeavor to provide adequate 
control, they suffer from significant problems. 

For example, First Bank's "Corporate Relocation Card" 60 
service allows an employee to use a credit card that is finked 
to an employer's account. It is intended that the employee 
will use the credit card to pay for certain types of expenses — 
i.e., those necessary for relocation. Due to the potential for 
abuse by an employee, the employer is permitted to control 65 
the types of expenses that the employee may charge to the 
credit card. 
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To do this, the employer designates certain classes of 
merchants (by Standard Industrial Classification ("SIC") 
code and/or Merchant Category Code ("MCC")) from which 
an employee may not purchase goods. The SIC code and/or 
MCC are associated with the credit card account in First 
Bank's database so that transactions for which a designated 
SIC code or MCC is received during the conventional 
transaction authorization process are declined. 

U.S. Pat. No. 4,873,422 to DethlofI entitled "Multi-User 
Card System" discloses a programmable card that is issued 
to a cardholder. The card can be programmed by the card- 
holder for use by a sub-user. The system allows the card- 
holder to set criteria by which the sub-user may use the 
card— e.g., a maximum amount of money that can be 
charged to the card and/or a time period in which the 
sub -user may use the card. In this way, the cardholder is able 
to gain some control over the ways in which the sub -user 
may use the card. Although the First Bank service and the 
Dethloff patent each provide an account holder with some 
ability to control a card-based transaction executed by a user, 
they do not permit an account holder to exercise this control 
remotely and based on circumstances surrounding the trans- 
action. 

U.S. Pat. No. 5,615,110 to Wong entitled "Security Sys- 
tem For Non-Cash Transactions" discloses a system and 
method in which an owner of a credit card is notiGed when 
the credit card is used for a transaction. According to this 
patent, if a transaction is "illegal" (e.g., executed by some- 
one other than the owner or is of a particular type), then the 
owner may use a telephone and contact the credit card issuer 
to stop the transaction. The Wong patent, however, does not 
enable communication between the owner and the person 
executing the transaction. 

U.S. Pat. No. 5,655,007 to McAllister entitled "Telephone 
Based Credit Protection" teaches a technique for verifying 
the identity of a cardholder. According to the McAllister 
patent, a conventional credit card authorization process is 
initiated by a merchant and suspended by a credit card issuer 
who is verifying the transaction. At the point-of-sale, a voice 
sample of the cardholder is taken and is transmitted via 
telephone to the credit card issuer's system. The credit card 
issuer's system matches the voice sample taken from the 
cardholder at the point-of-sale with a pre-recorded digital 
voice sample that was taken at an earlier time. If the two 
voice samples match, then the credit card issuer may autho- 
rize the transaction, assuming that the other criteria relating 
to conventional transaction authorization processing are 
met. Thus, the McAllister patent teaches a way to increase 
the security of transaction executed by a cardholder, but fails 
to teach a way for a cardholder to remotely control trans- 
actions executed by another user of the credit card. 

In view of the above, a substantial need exists for a 
method and system in which an account holder can com- 
municate with a user executing a card-based transaction and 
remotely control the authorization or denial thereof contem- 
poraneous with and based on circumstances surrounding the 
transaction. 

SUMMARY OF THE INVENTION 

A first aspect of the present invention is directed to a 
method for facilitating communication between first person 
(e.g., an account holder) and a second person (e.g., a user) 
so that the first person may authorize a transaction between 
the second person and a third party (e.g., a merchant). The 
method comprises the steps of linking the first and second 
persons to a financial account that is used for the transaction, 
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receiving data from the third party identifying the financial 
account and the third party, inquiring whether the first 
person desires to communicate with the second person based 
on the data identifying the financial account, receiving a 
response to the inquiry, and initiating communication 
between the first and second persons based on the response. 

A second aspect of this invention is directed to a method 
for facilitating communication between first and second 
persons so that the first person may authorize a transaction 
between the second person and a third party. The method 
comprises the steps of linking the first and second persons to 
a financial account that is used for the transaction, receiving 
data identifying the financial account and the third party 
from the third party, accessing a database based on the data 
identifying the financial account to determine a telephone 
number of the first person, and placing a telephone call to the 
first person based on the telephone number thereof, and 
inquiring whether the first person desires to communicate 
with the second person. If the first person responds affirma- 
tively to the inquiry, a database is accessed based on the data 
identifying the third party to determine a telephone number 
thereof and telephonic communication is enabled between 
the first and second persons using the telephone number of 
the third party. 

A third aspect of the present invention relates to a method 
for facilitating communication between an account holder 
and a user so that the account holder may authorize a 
card-based transaction between the user and a merchant. The 
method includes the steps of linking the account holder and 
the user to a financial account associated with the card that 
is used for the transaction, wherein the financial account is 
identified by an account number. The method further 
includes the steps of communicating with the third party to 
receive the account number and data identifying the third 
party, accessing a first database based on the account number 
to determine a telephone number of the first person, and 
attempting to contact the first person using the telephone 
number thereof. When the attempt to contact the first person 
is successful, an inquiry is made as to whether the first 
person desires to communicate with the second person. In 
response to an affirmative answer to the inquiry from the first 
person, a second database is accessed based on the data 
identifying the third party to determine a telephone number 
thereof and telephonic communication is enabled between 
the first and second persons using the telephone number of 
the third party. 

A fourth aspect of this invention is directed to an appa- 
ratus for facilitating communication between a first person at 
a first location and a second person at a point-of-sale 
location so that the first person may authorize a transaction 
between the second person and a third party at the point- 
of-sale location, wherein the first and second persons are 
linked to a financial account used for the transaction. The 
apparatus includes a memory storing data identifying the 
financial account and the third party, a first telephone 
number associated with the first location, and a second 
telephone number associated with the point-of-sale location. 

The apparatus also includes a processor in communication 
with the memory. The processor is adapted and configured 
to receive the data identifying the financial account and the 
third party from the third party, access the memory based on 
the data identifying the financial account and the third party 
to determine the first and second telephone numbers, trans- 
mit instructions to contact the first person based on the first 
telephone number, inquire whether the first person desires to 
communicate with the second person, and enable commu- 
nication between the first and second persons based on a 
response to the inquiry and the second telephone number. 



>7,348 Bl 

4 

BRIEF DESCRIPTION OF THE DRAWINGS 

Representative embodiments of the present invention will 
be described with reference to the following figures: 
5 FIG. 1 is a schematic illustration of an apparatus for 
facilitating communication between first and second persons 
so that the first person may authorize a transaction between 
the second person and a merchant. 

FIG. 2 is a diagrammatic representation of a server of the 
10 apparatus of FIG. 1. 

FIG. 3 illustrates a credit card account database of the 
server of the apparatus of FIG. 2. 

FIG. 4 illustrates a merchant database of the server of the 
apparatus of FIG. 2. 
15 FIG. 5 illustrates a user database of the server of the 
apparatus of FIG. 2. 

FIG. 6 illustrates a transaction database of the server of 
the apparatus of FIG. 2. 
2Q FIGS. 7A and 7B illustrate a process for processing a 
credit card transaction and for facilitating communication 
between first and second persons so that the first person may 
authorize a transaction between the second person and a 
merchant. 

25 DETAILED DESCRIPTION OF THE 

PREFERRED EMBODIMENTS 

Reference is now made to the accompanying Figures for 
the purpose of describing, in detail, the preferred embodi- 

3Q ments of the present invention. The Figures and accompa- 
nying detailed description are provided as examples of the 
invention and are not intended to limit the scope of the 
claims appended hereto. 

In accordance with the present invention, an account 

35 holder (or other authorized person) may permit a user to 
execute transactions with (i.e., purchase goods from) a 
merchant using a credit card that is linked to the account 
holder's credit card account. As used herein, a credit card is 
deemed to be "linked" to an account if a transaction involv- 

4Q ing the credit card affects the balance of the account. 

The invention allows the account holder to exercise 
control over the user's use of the credit card based on 
circumstances surrounding the transaction. This is achieved 
by enabling communication between the account holder and 

45 the user so that the account holder can determine the 
circumstances surrounding the transaction. For example, in 
an embodiment in which a parent permits a child to use a 
credit card only in emergency situations, the parent can 
communicate (e.g., telephonically) with the child to ascer- 

50 tain the nature of the emergency. In this way, the account 
holder can choose to authorize or decline the transaction 
based on the communication so as to effectively exercise 
control over the user's use of the credit card. 

FIG. 1 is a schematic illustration of a system for facili- 

55 tating communication between an account holder and a user 
so that the account holder may authorize a transaction 
between the user and a merchant. In this embodiment, the 
account holder is a parent who maintains a credit card 
account with an issuer. The user is a child of the parent that 

60 uses an identifier that is linked to the parent's account. Of 
course, in alternate embodiments an account holder may be 
any individual or organization who maintains a credit card 
account with an issuer and a user may be any individual or 
organization that uses a credit card that is linked to the 

65 account. 

Merchant 10 is a business with whom a user executes a 
transaction — i.e., uses a credit card to purchase goods. 
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Merchant 10 facilitates transactions at a point-of-sale by It is noted that the foregoing hardware may include 

using a card authorization terminal ("CAT") 15, such as well-known internal connectors, architectures, interfaces, 

those well known in the art, for transmitting a purchase ports, and communication devices (e.g., modems) to enable 

authorization request to server 30. As is well known in the processing and communication. For the purpose of simplic- 

art, a purchase authorization request includes data indicating 5 ity and clarity, a detailed description of the same is omitted, 

a purchase amount for the goods, an identifier that identifies Referring next to FIG. 2, a diagrammatic representation of 

a credit card that the user is presenting for payment, an an embodiment of server 30 is shown. Server 30 typically 

identifier that identifies a merchant 10, and an identifier that includes memory 110, and at least one processor 120 in 

identifies CAT 15 from which the purchase authorization communication therewith. Memory 110 typically includes 

request is transmitted. io one or more machine readable media. Such media include, 

Merchant 10 also has a telephone 20 that is accessible by as is well known in the art, an appropriate combination of 

a user. In this embodiment, telephone 20 is located at the magnetic, semiconductor and optical media. Memory 110 is 

point-of-sale and is in close proximity to CAT 15. In this preferably capable of supporting searching and storing of 

way, a user can have unfettered access to telephone 20. Of digital multimedia data such as text and audio. Memory 110 

course, other communications devices such as a computer 15 (or portions thereof) may reside on single computer, or may 

may be readily substituted for CAT 15 and/or telephone 20 be distributed in a known manner among multiple computers 

without departing from the spirit and scope of the present that may be included in server 30. 

invention. For example, CAT 15 and telephone 20 may be In the present embodiment, memory 10 includes credit 

combined in a single device such as the combination CAT/ card account database 200, merchant database 300, and user 

telephone disclosed in U.S. Pat. No. 3,793,624, the disclo- 20 database 400. Transaction database 500 may also be stored 

sure of which is incorporated herein by reference. in memory 110 to provide additional functionality. Memory 

CAT 15 and telephone 20 are in communication with 110 also stores program 600, which includes instructions for 

telecommunications network 25 via lines 15A and 20A, controlling processor 120 in accordance with the present 

respectively. In this embodiment, telecommunications net- invention, and particularly in accordance with the process 

work 25 is the well known public switched telephone 25 described herein. 

network (PSTN) and lines 15A and 20A are public telephone The rows and columns of the databases described herein 

lines. Of course, other communications networks and lines represent records and fields thereof, respectively. In the 

may be used as desired. described embodiments, the databases are used in a rela- 

A telecommunications switch 32 (e.g., a PBX) is in 3Q tional arrangement, as is known in the art, so that the 

communication with telecommunications network 25 via databases relate to one another by way of fields that store 

line 32 A, Telecommunications switch 32 also is in commu- common data. It is noted that while the following description 

nication with server 30 via line 30Aand an interactive voice refers to specific individual databases, formats, records, and 

response unit ("IVRU") 34 via line 34A. IVRU 34 commu- fields, those skilled in the art will readily appreciate that 

nicatcs with server 30 via line 34B. IVRU 34 provides an 35 various modifications and substitutions may be made thereto 

interface between server 30 and an account holder, allowing without departing from the spirit and scope of the present 

voice prompts to the account holder and transmitting signals invention. 

received from the account holder to server 30, as will be Referring now to FIG. 3, an embodiment of credit card 

further described below. Telecommunications switch 32, account database 200 is depicted in detail. Database 200 

IVRU 34, and lines 30A, 32A, 34A, and 34B are well known 4Q stores data relating to credit card accounts that are main- 

and therefore are not described here further. See, for tained for account holders. Each record (row) of database 

example, U.S. Pat. No. 4,847,890, the disclosure of which is 200 represents such an account. For exemplary purposes, 

incorporated herein by reference. two records Rl and R2 are shown. 

Server 30 includes one or more computers that are pref- Field 2 00 A stores an account identifier that is associated 

erably located at one physical location. Alternatively, server 45 with and that uniquely identifies a credit card account. In this 

30 may include multiple computers that are connected via a embodiment, the account identifier is a sixteen digit credit 

network that spans multiple physical locations, thereby card account number, such as is commonly imprinted on a 

allowing the computers to communicate with each other via credit card. Thus, as is well known, the first four digits of 

well known communication techniques. In this way, as is each account number indicate the issuer of the credit card, 

well known in the art, memory and processing may be 50 The remaining twelve digits of each account number are 

distributed among the computers that may make up server used to uniquely identify an account. Of course, other types 

30. of account identifiers may be used as desired. 

Server 30 is operated by or associated with an entity or Field 200B may be used to store the name of an account 

organization (referred to as the "entity") that maintains data holder. In one embodiment, the name stored in field 200B is 

relating to account holders* credit card accounts. In the 55 a digital audio file (or a pointer thereto) that contains a 

described embodiments, the entity is a credit card issuer. Of pre-recorded audio sample of the account holder's name. Of 

course, the entity may be a credit card processing company course, an account holder's name may be stored in field 

that operates a network for facilitating processing of credit 200B in another form, such as text, 

card transactions, such as First Data Corporation. Field 200C may be used to store the address of an account 

Telephone 35 is a telephone that is capable of generating 60 holder. Fields 200D and 200E may be used to store a credit 

Dual Tone Multi-Frequency ("DTMF") signals, and that is line and available credit for an account, respectively, 

accessible by an account holder (or other designated person). Referring next to FIG. 4, an embodiment of merchant 

Telephone 35 is in communication with telecommunications database 300 is depicted in detail. Database 300 stores data 

network 25 via line 35 A, which in this embodiment is a relating to one or more merchants 10 with whom a user may 

public telephone line. Of course, other communications 65 execute transactions. One record (row) of database 300 is 

devices may be readily substituted for telephone 35 as maintained for each merchant 10. For exemplary purposes, 

desired. two records R3 and R4 are shown. 
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Field 300A stores a merchant identifier that uniquely 
identifies a merchant 10. For exemplary purposes, the mer- 
chant identifier is shown as including five digits. 

Field 300B may be used to store a CAT identifier that 
identifies a particular CAT 15 of merchant 10. Field 300C 
stores a telephone number for a telephone 20 that is acces- 
sible by a user. Id this embodiment, telephone 20 is located 
at the point-of-sale and is in close proximity to CAT 15 that 
is identified by the CAT identifier stored in field 300B. 

Field 300D may be used to store a name of a merchant 10. 
The name may be stored in the form of a digital audio file 
(or a pointer thereto) that contains a pre-recorded audio 
sample of the name of merchant 10. Of course, a merchant's 
name may be stored in field 300B in another form, such as 
text. 

Referring next to FIG. 5, an embodiment of user database 
400 is depicted in detail. Database 400 stores data that 
enables an account holder to communicate with a user to 
determine at least a portion of the circumstances surround- 
ing a transaction that is being executed by the user. One 
record (row) of user database 400 is maintained for each 
credit card that is linked to a credit card account represented 
by a record in database 200. For exemplary purposes, two 
records R5 and R6 are shown. 

Field 400A stores a user identifier that is associated with 
and that uniquely identifies a credit card that is linked to a 
credit card account represented by a record in database 200. 
In this embodiment, the identifier stored in field 400A is a 
sixteen digit credit card account number, such as the type 
commonly imprinted on a credit card. As will be described 
in more detail below, a user uses the credit card identified by 
the identifier stored in field 400A to execute a transaction 
with a merchant 10. Field 400B stores an account identifier 
that is associated with and that uniquely identifies a credit 
card account to which the credit card identified by the user 
identifier stored in field 400A is linked. 

In this embodiment, the user identifier stored in field 400A 
is made to differ from the account identifier stored in field 
200A so that the presentation of a user identifier would 
initiate transaction process 601. Preferably, the length of the 
user identifier is the industry standard length of sixteen 
digits. Of course, the user and account identifiers stored in 
fields 400A and 200 A may be designed to be the same. In 
this case, field 400B would not be necessary. 

Field 400C stores a fee that is charged to the balance of 45 
the account holder's account for each transaction initiated by 
the presentation of user identifier 400A. The fee may be 
determined in a number of different ways. For example, the 
fee may be based on the amount of time that an account 
holder communicates with a user or it may be a fixed dollar 
amount that is charged to the balance each time that a credit 
card is used by a user. In another embodiment, the fee may 
be charged on a periodic basis — e.g., each year, regardless of 
the number of times that a credit card is used. In still another 
embodiment, the fee may be a percent of the transaction 
amount. In any of these embodiments, the fee also may be 
made to vary in accordance with the type of credit card. For 
example, if a credit card is a "gold" card, then a $25 annual 
fee may be charged. Alternatively, if a credit card is a 
"platinum" card, there may be no associated fee. 

Field 400D may be used to store the name of a user. The 
name stored in field 400D may be a digital audio file (or a 
pointer thereto) that contains a pre-recorded audio sample of 
the user's name. Alternatively, a user's name may be stored 
in field 400D in another form, such as text. 

Field 400E is used to store a telephone number of a 
telephone 35. In the present embodiment, it is the telephone 
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number of an account holder. In alternate embodiments, it 
may be a telephone number of another person, such as a 
relative of the user. 

Field 400F may be used to store a length of time (e.g., a 
number of minutes) that an attempt will be made to contact 
an account holder (or other person) at telephone 35 using the 
telephone number stored in field 400E. If this time elapses, 
a default command stored in field 400G may be executed. In 
one embodiment, the default command indicates whether a 
transaction should be authorized or declined in the event that 
the account holder (or other person) cannot be contacted. 

FIG. 6 depicts, in detail, an embodiment of transaction 
database 500. Database 500 may be used to store data 
relating to transactions executed by a user using a credit card 
that is linked to an account stored in database 200. It may 
also be used to store data relating to conventional transac- 
tions involving other credit cards. For exemplary purposes, 
three records R7-R9 are shown. 

Field 500A is used to store either a user identifier or an 
account identifier. If a record represents a transaction 
between a user and merchant 10 in which a credit card that 
is linked to a credit card account represented by a record in 
database 200 was used, then a user identifier stored in field 
500A identifies that credit card, as described above with 
reference to field 400A (FIG. 5). Records R7 and R8 
represent such records. If a record represents a transaction 
between an account holder and a merchant using another 
credit card, then the identifier stored in field 500A represents 
the credit card number of that credit card. Record R9 
represents such a record. 

Field 500B stores an authorization code that is generated 
in a well-known manner by server 30 when it authorizes a 
transaction. Field 500C stores a record of charge identifier 
that is printed on a receipt and used to help the user and/or 
the account holder identify the transaction. The identifier 
stored in field 500C is generated by server 30 in a well 
known manner. Field 500D stores either a dollar amount 
spent by a user for a transaction or a fee that is to be charged 
to the credit card account, the latter of which is described 
with reference to field 400C (FIG. 5). 

Field 500E may be used to indicate whether the value 
stored in field 500D represents such a dollar amount or a fee. 
As shown in record R7, if the charge description stored in 
field 500E indicates a name of a merchant 10 (e.g., "ABC 
Drug Store"), then the amount stored in field 500D repre- 
sents a transaction amount, here, $250.38. For example, as 
shown in record R8, if the charge description stored in field 
500E indicates "Emergency Card Usage Fee," then the 
amount stored in field 500D represents a fee — e.g., $20.00. 
Fields 500F and 500G store a merchant identifier and a CAT 
identifier, respectively, as described above with reference to 
field 300A and 300B, 

It is noted that given a first record relating to a transaction, 
a second record relating to an associated fee may be deter- 
mined. This is because the first and second records will have 
identical user identifiers stored in field 500A. Thus, for 
example, record R7 represents a transaction for "S250.38" 
and record R8 represents an associated "$20.00" usage fee. 
Consequently, both records R7 and R8 have the same user 
identifiers— i.e. , "2222-3333-4141 -5151 ." 

Referring again to FIG. 2, memory 110 also includes 
program 600. Program 600 comprises computer instructions 
and/or data, executable or otherwise, for performing the 
functionality of the present invention. FIGS. 7 A and 7B 
depict process 601 that may be embodied by such a program 
600 for processing a credit card transaction and facilitating 



06/04/2004, EAST version: 1.4.1 



US 6,327,348 Bl 

9 10 

communication between first and second persons so that the processor 120 will authorize the transaction in a conven- 
first person may authorize a transaction between the second tional manner. Alternatively, if the retrieved default corn- 
person and a merchant. mand is "DECLINE," then processor 120 will decline the 

Prior to execution of process 601 it is contemplated that transaction in a conventional manner. If this feature is not 

an account holder and a user have been linked to a credit 5 included and the account holder cannot be contacted, then 

card account for which a record is maintained in database the transaction may be terminated. If it is determined at step 

200 (FIG. 3). This may be accomplished via a registration- 614 that the account holder has been contacted, then at step 

type process whereby a user is registered with a credit card 618 processor 120 instructs IVRU 34 to present a list of 

such that transactions executed with the credit card will options to the account holder. For example, IVRU 34 may 

affect the balance of the account holder's account. io cause the following message to be played to the account 

At step 602, a user begins to execute a transaction with a holder: "Hello MUflhoaoiu you have a transaction autho- 

merchant 10. To do this, the user presents a credit card that rizatl0n ^quest n from ^ Smith for $250^38 at 

is linked to an account stored in database 200 (FIG. 3) to a ABC Pmg Store . Press 1 if you wish to authorize this 

merchant 10 for payment. The credit card has an identifier transaction. Press 2 if you wish to decline this transaction 

imprinted thereon and/or encoded therein, which corre- " 3 lf 3™ ™sh to taUj twitfa I<*finifli. The underlined 

sponds to a user identifier stored in field 400 of database 400 text ma V be P 1 ^ b V ™ 34 t0 ^ e *<*°T bolder b y 

CF1G 5} accessing the relevant voice files, or other data in the case of 

. w . • u * m ox-ric a monetary amount, in the appropriate databases. The 

Using conventional techniques, merchant 10 uses CAT 15 r, , , , *u a k«, «i » «o » 

4 , fa , - J 44 , A . account holder responds by depressing the number "1, "2, 

to transmit a purchase authorization request to server 30 via . . a f.\ u ie a • i * a- *■ 

1eA 4 ; . .. . i «a # i 20 or "3 on the keypad of telephone 35 and a signal indicative 

fine 15A, telecommunications network 25, Une 32A, tele- f . i v 4 ... *\ . m • ^ 

• •* u M j * • - nA L IP iX ... of the response is transmitted to server 30 in a conventional 

communications switch 32, and une 30A (FIG. 1). In this / %4 4 ... . . f .. 

, 4 . i j , « ■ r u manner. In an alternate embodiment, the list of options may 

embodiment, the request includes data indicating a purchase . 4 , 4 4 , . . , . w„ „ u ~ f _ 

. c \ ~j . , ,. r t , 4 . , ,r be presented to the account holder by a human operator, 

amount for the goods, an identifier that identifies the credit r J r 

card that the user is using for payment, an identifier that At step 620, processor 120 determines whether the 

identifies merchant 10, and an identifier that identifies CAT 25 account holder desires to communicate with the user. If 

15 from which a purchase authorization request is being processor 120 received a signal indicating that the user 

transmitted. The purchase authorization request may be depressed the number "1" or "2" on his keypad, then the 

routed through a credit card processing network (not shown) account holder does not desire to communicate with the user 

to server 30 in a well known manner. Server 30 receives the and processing continues at step 622. 

purchase authorization request from CAT 15. 30 If processor 120 received a signal indicating that the user 

At step 604, processor 120 of server 30 accesses the depressed the number "3" on his keypad, then the account 

record in user database 400 whose field 400A corresponds to holder does desirc t0 communicate with the user. In this 

the identifier that identifies the credit card that was received case, at step 624, processor 120 enables or initiates com- 

at step 602. Processor 120 retrieves the account identifier munication between the account holder and the user. In this 

stored in field 400B for the accessed record. Processor 120 embodiment, processor 120 accesses the record in merchant 

accesses the record in credit card account database 200 for database 300 whose field 300B corresponds to the CAT 

the retrieved account identifier and retrieves the available identifier that was included in the purchase authorization 

credit stored in field 200E, At step 606, if the available credit request received at step 602. Processor 120 retrieves the 

stored in field 200E is determined to be less than the An telephone number stored in field 300C for that record. 

40 

purchase amount received at step 602, then the transaction The retrieved telephone number is used by IVRU 34, 

is terminated at step 608 and process 601 is complete. under control of processor 120 and telecommunications 

If the available credit stored in field 200E is determined switch 32, to place a telephone call to the user at telephone 

at step 606 to be greater or equal to the purchase amount 20 in the proximity of CAT 15. The method and apparatus 

received at step 602, then processing continues. At step 610, 45 disclosed in U.S. Pat. No. 5,319,701, incorporated herein by 

processor 120 retrieves the name of the user and the account reference, may be used to establish connection between 

holder's telephone number from fields 400D and 400E, telephone 35 and telephone 20 so that the account holder 

respectively, for the record in user database 400 that was may communicate with the user before authorizing or 

accessed at step 604. Processor 120 also retrieves the name declining the transaction at step 622. 

of the account holder from field 200B for the record in credit 50 The account holder and the user may communicate to 

card account database 200 that was accessed at step 604. discuss the circumstances surrounding the transaction. For 

An inquiry is made whether the account holder desires to example, consider an account holder who has a parental 
communicate with the user. In this embodiment, at step 612, relationship with the user. Further consider that the parent 
the telephone number retrieved at step 610 is used by IVRU permitted the child to use the credit card only in cases of 
34, under control of processor 120 and telecommunications 55 emergency. In such an instance, the parent and child may 
switch 32, to attempt to connect the account holder. Thus, communicate to discuss the nature of the emergency. In one 
IVRU 34 places a telephone call to telephone 35 using that embodiment, processor 120 is configured to track the dura- 
telephone number in a conventional manner. tion of the communication so that a fee can be charged to the 

At step 614, it is determined whether the account holder financial account based on the duration, 
has been contacted. If the account holder has not been 60 At step 622, based on the communication, the account 
contacted, then a feature of the present invention may be holder can authorize or decline the transaction using tele- 
executed at step 616. In accordance with this feature, if the phone 35. To do so, the account holder depresses the number 
account holder cannot be contacted within the period of time "1" or "2" on the keypad of telephone 35. A signal indicative 
specified in field 400F for the record in user database 400 of that response is transmitted to server 30 in a conventional 
accessed at step 604, then the default command stored in 65 manner at which point the command is executed. In an 
field 400G for that record is retrieved and executed. Thus, if alternate embodiment, the account holder may enter a per- 
the retrieved default command is "AUTHORIZE," then sonal identification number via the keypad of telephone 35 
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in order to authorize or decline the transaction. In this case, 
the signal transmitted to server 30 comprises a personal 
identification number. At step 626, processor 120 continues 
processing the transaction in accordance with the response 
of the account holder at step 618 or 624. Thus, if the account 5 
holder authorized the transaction, then an authorization code 
is generated in a conventional manner, which is transmitted 
to CAT 15 that communicated the purchased authorization 
request to server 30 at step 602. The transaction database 
500 is updated as follows: the identifier identifying the credit JQ 
card, the purchase amount, the identifier identifying the 
merchant, and the CAT identifier received in the purchase 
authorization request at step 602 are stored in fields 500A, 
500D, 500F, and 500G, respectively. 

An authorization code is generated and stored in field 
500B. The record charge identifier is stored in field 500C. 15 
The charge description is obtained from the merchant data- 
base 300 by reading field 300D for the record identified by 
the merchant identifier received in the purchase authoriza- 
tion request received at step 602. 

At step 628, a record is also populated in the transaction 20 
database 500 to reflect the emergency charge. More 
specifically, the identifier identifying the credit card, the 
identifier identifying the merchant, and the CAT identifier 
received in the purchase authorization request at step 602 are 
stored in fields 500A, 500F, and 500G, respectively. The 25 
transaction usage fee is obtained from user database 400 and 
is stored in field 500D. An authorization code is generated 
and stored in field 500B. The record charge identifier is 
stored in field 500C. The charge description "Emergency 
Card Usage Fee" is stored in field 500E. Process 601 ends 30 
at step 630. 

In an alternate embodiment, communication with mer- 
chant 10 may be terminated prior to accessing database 400 
at step 610 to determine the telephone number of the account 
holder. In this way, processor 120 of server 30 may receive 35 
a signal from an account holder indicating whether to 
authorize the transaction. When the signal indicates that the 
transaction is to be authorized, processor 120 of server 30 
may re-establish communication with merchant 10 and 
transmit an authorization code thereto. According to another 40 
embodiment of this invention, if the account holder has not 
been contacted at step 612, then processor 120 may instruct 
IVRU 34, under control of processor 120 and telecommu- 
nications switch 32, to attempt to contact another person 
(e.g., a relative of the user) who can authorize or decline the 45 
transaction. Also, the other person may be selected from 
among several people depending on the time of day that the 
data identifying the financial account and the third party is 
received. In this case, user database 400 may be modified in 
a well known manner to include the name(s) and telephone 50 
numbers) of each person, as well as the time of day that a 
person is to be contacted if this latter embodiment is 
implemented. Each person may be contacted as described 
above with reference to the account holder and processing 
would proceed as if the person was the account holder. 55 

In view of the foregoing, the present invention provides a 
method and apparatus in which an account holder can 
remotely control the authorization or denial of a card-based 
transaction executed by a user. The method and system 
enable the account holder to communicate with the user who 60 
is using a credit card to execute the transaction with a 
merchant. In this way, the account holder and the user can 
discuss the circumstances surrounding the transaction and 
the account holder can authorize or decline the transaction 
based on those circumstances. Thus, the account holder is 65 
able to adequately control and manage charges made by 
users using credit cards that are linked to their accounts. 
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While the foregoing embodiments have been described 
with reference to a credit card and corresponding credit card 
account, it is contemplated that other types of cards and 
financial accounts may be used. Such financial cards may 
include, for example, debit cards and smart cards and their 
associated financial accounts. 

To illustrate still other alternate embodiments, consider 
that control of cash withdrawal at an Automatic Teller 
Machine (ATM) can be remotely authorized by the account 
holder upon presentation of the user identifier 400A at the 
ATM. In this embodiment, the communication between the 
account holder and the user can be facilitated using audio 
and/or video transmission. In an audio-based embodiment, 
communication may be facilitated using the above- 
referenced telephone connections. In a video-based 
embodiment, communication may be facilitated between a 
personal computer or video phone connected to the ATM 
network and the ATM. In this video embodiment, video 
images of the parties may be input through video cameras 
and transferred during the communication. The personal 
computer may use well known video cameras, such as those 
commonly manufacture by Intel Corp. The ATM may use its 
resident security camera. As such, the account holder is able 
to see a graphical image of the user on the screen of the 
account holder's personal computer during the transaction to 
ensure that the user presenting a card having user identifi- 
cation number 400A is in fact authorized. 

Thus, although the particular embodiments shown and 
described above are useful in many applications relating to 
the arts to which the present invention pertains, further 
modifications of the present invention herein disclosed will 
occur to persons skilled in the art. All such modifications are 
deemed to be within the scope and spirit of the present 
invention as defined by the appended claims. 

We claim: 

1. A system for facilitating communication between first 
and second persons so that the first person may authorize a 
transaction between the second person and a third party, the 
system comprising: 

means for linking the first and second persons to a 

financial account that is used for the transaction; 
means for receiving data from the third party identifying 

the financial account and the third party; 
means for inquiring whether the first person desires to 

communicate with the second person based on the data 

identifying the financial account; 
means for receiving a response to the inquiry from the first 

person; and 

means for initiating communication between the first and 
second persons based on the response. 

2. The system of claim 1, further comprising: 

means for receiving a signal from the first person indi- 
cating whether or not to authorize the transaction; and 
means for processing the transaction based on the signal. 

3. The system of claim 2, wherein the signal indicates a 
personal identification number. 

4. The system of claim 1, wherein the means for inquiring 
comprises: 

means for accessing a voice file stored in a memory; and 
means for causing an IVRU to play the voice file to the 
first person. 

5. The system of claim 1, wherein the communication 
between the first and second persons has a duration associ- 
ated therewith, and wherein the system further comprises 
means for charging a monetary amount to the financial 
account based on the duration associated with the commu- 
nication. 
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6, The system of claim 1, further comprising means for 
selecting the first person from a plurality of persons. 

7, The system of claim 1, further comprising means for 
selecting the first person from a plurality of persons depend- 
ing on the time of day that the data identifying the financial 
account and the third party is received. 

8, The system of claim 1, further comprising when a 
response to the inquiry is not received from the first person 
within a predetermined period of time, means for accessing 
a memory to determine whether the transaction is to be 
authorized or declined. 

9, The system of claim 1, further comprising: 

means for determining a first telephone number associated 
with the first person based on the data identifying the 
financial account; 

means for placing a telephone call to the first person based 
on the first telephone number; 

means for determining a second telephone number asso- 
ciated with the third party based on the data identifying 
the third party; 

means for receiving a signal from the first person, in 
which the signal indicates whether to authorize a trans- 
action between the second person and the third party; 
and 

means for processing the transaction based on the signal, 
in which means for initiating communication comprises: 
means for initiating telephonic communication 

between the first person and the second person based 

on the second telephone number. 

10, The system of claim 1, further comprising: 

means for receiving a first signal from the first person, the 
first signal indicating whether to authorize a transaction 
between the second person and the third party; and 
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means for transmitting a second signal to the third party 
if the first signal indicates the transaction is to be 
authorized, the second signal authorizing the transac- 
tion. 

11. The system of claim 1, in which the data identifying 
the financial account comprises a credit card number. 

12. The system of claim 1, in which the financial account 
is a credit card account. 

13. The system of claim 1, in which the first person owns 
the financial account. 

14. The system of claim 1, in which the third party is an 
automatic teller machine. 

15. The system of claim 1, further comprising: 

means for storing an indication of a transaction between 
15 the second person and the third party. 

16. The system of claim 1, in which means for initiating 
communication comprises a telephone in communication 
with a telecommunications network. 

17. The system of claim 1, in which the data identifying 
20 the financial account comprises a sixteen digit number. 

18. The system of claim 1, further comprising: 

means for charging a fee to the financial account based on 
a transaction between the second person and the third 
party. 

19. The system of claim 1, in which the data identifying 
the financial account corresponds to a credit card. 

20. The system of claim 1, in which the means for linking 
comprises: 

means for associating the second person with a credit 
card, in which the credit card corresponds to the 
financial account, and in which the first person owns 
the financial account. 
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